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INTRODUCTION 


The SSES Managers Guide and the final version of the NSSC-II 
computer brochure are presented in the first section of this report. 
Section 2 contains the sunmary of the work accomplished for each of the 
scope of work tasks for this contract. 



1. SSES MANAGERS GUIDE 


SAI has developed a11 of the following components of the SSES 
System: a software requirements methodology, a software design language, 
a structured programming language, a static code analyzer, a dynamic code 
analyzer, and a testcase generator. Each of these has self explanatory 
technical and user documentation as listed In Table (1). As far as overall 
guidelines In managing the personnel of a software project, we refer the 
Interested reader to SAI Programming Guidelines, April/May 1978 SAI Progress 
Report. This report Indicates how to structure the responsibilities of the 
software Implementation and test teams. In terms of overall resources. 
Implementation and test should account for about 50% of the total development 
effort; the other 50% should go to software requirements and design. For 
these stages SSES provides a requirements methodology and a design language. 
The requirements approach Is a modified HIPO-type description of the requlre- 
. ment functions and subfunctions. In order to Identify these functions, we 
recommend the creation of Data Flow Diagrams (c.f. DeMarco, Structured 
Analysis and Design, Yourdon Press) which use data as a starting point. Once 
all the data flows have been established, the processing points can be 
elaborated using the SSES requirements methodology. Another advantage of 
using DFD's Is that they lead to a natural high level software design - as 
Illustrated In Figure (1). Once established, this design can be expressed 
In terms of SSL - the SSES design language. 

One last point we should make Is about the cost and scheduling of 
software. The very best reference we can give on that topic 1s an article 
by Alvin L. Kustanowitz, which we Include In the appendix of this report. 

In retrospect, we think there are a wide variety of reasons why 
an integrated system of software development tools should be employed - for 
Increased reliability, quicker development, better maintainability, etc., 
but one reason which should stand out to all Is lower cost. Attesting to 
this fact is Table (2) which g'Jves productivity figures obtained while 
developing the various SSES tools - along with a pilot project - a relational 
data base management system. These programs were developed using some or 
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all of the SSES tools. Once the SSES developed programs are categorized as 
to type of development, their productivity figures compare favorably with 
Industry standards. Even the relational DBMS program - which was a highly 
theoretical, non-standard development - had favorable results. We believe 
that through using the tools of the SSES system, predicting productivity of 
10 llnes/day for any HOL program will be an entirely safe and certain 
estimate. 


TECHNICAL DOCUHENTATICW EOR 
SSES COMPONENTS 
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TABLE 2. CODE LINES/DAY OVER ENTIRE DEVELOP»€NT 
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2. QUAHTITATIVE PROGRESS 


SOW Task 


X Coffpleted 


Action Taken 


A. Develop Pilot Software 

B. Test and Evaluate 
SSES Components 


lOO We have bulU a relational Data 
Base Management System using 
SSES. 

100 An* SSL report, written by an 

Independent evaluator, was sub- 
mitted In our July 1, 1977 Pro- 
gress Report. Also, the dynamic 
analyzer, static analyzer and 
structured preprocessor have 
been tested and evaluated at 
another NASA computer center at 
MSFC as well as the John Hopkins 
Applied Physics Lab. 


C. Modification of 100 

SSES Components 


0. Advanced Research 100 


E. 

NSSC-II Software Documen- 

100 


tation and HAL/S Software/ 



Assessment 


F. 

HAL/S and FORTRAN Comparison 

100 

G. 

NSSC-II Documentation 

100 


FACES, the structured* FORTRAN 
preprocessor, and two versions 
of the dynamic analyzer have 
been converted to the UNIVAC 
1108. SSL was modified to 
Improve error recovery. Extend- 
ing the analyzing capabilities 
and decreasing the execution 
overhead was accomplished for the 
dynamic analyzer. 

Documented In our August 1977 
Progress Report was an Investi- 
gation of the SSES system to- 
wards microprocessor software. 
Our extensive research Into the 
data bases was partiallv reflect- 
ed In our October (1977) Progress 
Report. A paper entitled, "Com- 
puter Program Development 
Analysis" was written which 
appears In Appendix A of the 
September 1978 report. 

Documentation has been completed. 


Small comparison program was run 

Documentation is completed and 
has been printed. 
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SYSTEM LIFE CYCLE ESTIMATION (SLICE): 
A NEW APPROACH TO ESTIMATING RESOURCES 
FOR APPLICATION PROGRAM DEVELOPMENT 


Alvin L. Kustanowitz 


IBM Corporation 
Data Processing Division 
White Plains, New York 10604 


ABSTRACT 


This paper presents a technique for 
the accurate estimation of manpower 
required to implement programming 
applications, from simple batch programs 
to complex, on-line systems in both the 
conventional and top-down, structured 
programming environments . 

The history of estimating techniques 
is reviewed in order to show why most of 
them have failed to produce accurate and 
consistent results, and to demonstrate 
the need for a fresh approach to re- 
source estimation. 

The technique. System Life Cycle 
Estimation (SLICE), has greatest val- 
idity -when a system design already 
exists, but may be used, although with 
less accuracy, at earlier stages of 
development . 


THE HISTORY OF ESTIMATING TECHNIQUES 

Ever since the appearance of the first 
programmable computer, we have been 
trying to predict, forecast and estimate 
how long it will take and how much it will 
cost to develop programs and programming 
systems. Almost without exception, these 
efforts have failed. Certainly, some 
wel 1 - conceived estimating techniques 
have been published because their devel- 
opers found them to be useful in a 
particular environment. - In most of these 
cases, the authors were very careful to 
describe the environment for which the 
technique was suited, and to advise poten- 
tial users of its limitations and restric- 
tions. 

J. D. Aron, in a paper that has become 

a classic in the fieldl, suggests a 
quantitative approach using 20 assembly- 
language source statements per day for 
"easy" programs, 10 per day for "medium" 
programs and 5 per day for "hard" programs. 
While these figures have been widely used 
and quoted, applying them to a typical 
program or system doesn't always result in 


accurate estimates. Careful reading of 
the paper shows why--the figures are 
applicable only for "large" systems, 
where these are defined as requiring: 

* More than 2S prc^'ammers 

* More than 3O,00C eliverable instruc- 
ions 

* More than six months development 
time 

* More than one level of management 

Furthermore, the definitions of "easy", 
"medium" and "hard" are themselves re- 
vealing . 

EASY - Very few interactions with other 
systems elements. The class 
includes most problem programs 
or "application" programs. Any 
program the main function of 
which is to solve a mathematical 
or logical problem is probably 
in this class. Easy programs 
generally interact only with in- 
put/output programs, data 
management programs, and monitor 
programs . 


MEDIUM - 


Some interactions with other 
system elements. In this cate- 
gory are most utilities, lang- 
uage compilers, schedulers, in- 
put/output packages and data 
management packages. These pro- 
grams interact with hardware 
functions, with problem programs, 
with monitors, and with others 
in this class. They are further 
complicated by being generalized 
enough to handle multiple sit- 
uations; e.g.,I/0 from many 
different I/O devices or man- 
agement of data files with 
variable numbers of indices. 


- Many interactions with other 
system elements. All monitors 
and operating systems fall in 
this class because they Interact 
with everything. Special pur- 
pose programs, such as a con- 
versational message processor, 
may be in this class if they 
modify the master operating system. 


I 


i 


It becomes apparent that most applica- 
tions which a company is likely to under- 
take, such as payroll, personnel, inven- 
tory, sales analysis, accounts 
receivable and payable and even on-line 
systems developed with the aid of tele- 
processing control systems and data 
base management systems, fall into the 
"easy" category. Only if the effort is 
one of developing a package like a data 
base management system does the degree of 
difficulty move up into the "medium" 
category. 

Clearly, while this approach ma/ have 
been useful in its context, which is the 
development of such systems as the SABRE 
airline reservation system and the 
Operating System (OS) for IBM's family 
of 360 and 370 computers, it is not 
directly applicable to the wide range of 
programs which a typical company is 
likely to design and implement. 

In "Management Planning Guide for a 
Manual of Data Processing Standards"^, 
there is a section called "Technique for 
Estimating Project Duration." In it, the 
user is led through an elaborate scheme 
of applying weighting points for program 
complexity, input/output characteristics, 
major processing functions, programming 
know-how and programmer job knowledge. 

Program development time is computed by 
multiplying the sum of the first three sets 
of weights by the sum of the last two sets. 
After calculating this to two decimal pla- 
ces, we are told to add an additional 70 
to 110% for "other system time." 

The use of decimal places in these cal- 
culations is particularly subject to 
misinterpretation because precision 
usually implies accuracy, which is clearly 
not the case here. 

If these published techniques don't 
work for typical business applications, how 
then, do we estimate the resources re- 
quired? 

SYSTEM LIFE CYCLE ESTIMATION (SLICE) 

The Basic Method 


All prograiming projects have one thing 
in common: A Life Cycle. They begin, and 

sooner or later, they end. Between the 
starting and ending points, the develop- 
ment effort proceeds through a succession 
of distinct phases. The number and com- 
position of these phases will vary, de- 
pending on the size and complexity of the 
project, and the installation standards 
and procedures for such activities as 
project management, program and system 
testing and documentation. 

Most attempts to produce "standard" 
estimating techniques have failed because 
of the impossibility of imposing one 
organization's standards on others. 

Another point of difference is to what 
part of the development cycle we are 
applying an estimating technique. 

The point here is that, unless all 
those trying to estimate the development 
cost of a project agree on the system life 
cycle or profile for this- project and to 
which portion of the cycle they are ap- 
plying productivity factors, the only 
result is confusion. 

Of course, it must be understood that 
any estimates will be virtually useless 
unless an organization has implemented 
and is committed to project control 
standards. Without such standards, 
changes are likely to occur during the 
development cycle which will distort or 
even totally invalidate the original 
estimates . 

Ask atiy programmer of programming 
manager to describe the stages of develop- 
ment of a programming system. The most 
likely answers will be: 

DESIGN- -CODE --TEST DESIGN- -CODE --TEST 

OR 

30% 40% 30% 1/3 1/3 1/3 

These classic distributions, although 
universally used, are actually meaningless 
when applied to one particular project. 

If the project consists of a single program 
to do a simple summation of numbers and 
print out the result, the distribution is 
more likely to be 10-80-10 than 30-40-30 
because design and testing are trivial 
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whilt most of the work will be in coding 
•nd compiling. At the other extreme, if 
the project is an on-line real-time 
airlines reservation s/stern or all the 
programming required for a manned 
landing on Mars, the distribution might 
be 4S-10-4S, with the coding a relatively 
small part of the total effort compared 
to the years of design and extensive 
multiple levels of unit, integration, 
system and regression testing. 


plan. 

How To Use Slice: A Step-by-Step Approach 

Describe Your Project Life Cycle 

In the preceding section, we discussed 
the relative proportions of design, code 
and test in different projects. Usually, 
these three phases are further broken 
into smaller components such as: 


This continuous range of distributions 
for projects of different size is shown 
graphically in Figure 1. 


100 


TEST 

TEST 

TEST 

10-20% 

20-30% 

30-45% 

CODE 

CODE 

CODE 

60-80% 

40-60% 


DESIGN 

design 

DESIGN 

10-20% 

20-30% 

30-45% 


SMALL INTERMEDIATE LARGE 
PROJECT SIZE 


figure 1. SYSTEM LIFE CYCLE VARIES WITH 
PROJECT SIZE 

The essence of System Life Cycle 
Estimation is the realization that no 
two system development efforts are the 
same, especially when they are implemented 
in different organizations; however, if 
.multiple systems are developed in the same 
environment, they will shaxc many charac- 
teristics and the experience gained in the 
first, if quantified through accurate 
record-keeping techniques, will serve as 
a sound basis for estimation of its 
successors . 


Once the estimator accepts this line of 
reasoning, he can proceed to define a 
realistic model of the proposed system in 
its real environment, apply known percent- 
ages and productivity factors and 
translate the raw number of technical man- 
days so derived into a time-phased project 


Planning 

Feasibility Study 

Requirements Definition 

Conceptual Design 

Program Design 

Data Base Design 

Program Specifications 

Program Flowcharting 

Coding 

Compilation 

Data Base Creation 

File Conversion 

Unit Test 

Integration Test 

System Test 

Documentation 


The first setp In using System Life 
Cycle Estimation is to construct, from 
the categories listed above, and any 
others you may add, a project profile 
describing system development as you see 
it based on actual operation of your 
company, division, group or department, 
and based on previous projects completed 
in the same environment. Project size 
should have little bearing on this step. 
Here are some examples: 


PROFILE A 


1. Functional Requirements Study 

2. Conceptual System Design 

3. General System Design 

4. Program Specifications 

5. Coding 

6. Compilation and Unit Test 

7. System Test 

PROFILE B 

1. Planning 

2. Program Design 
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3. Data Base/File Design 

4. Prograaning 

5. Data Base Creation 

6. Testing 


START 


FUN CON DES 

SPC 

COD 

UNI 

SYS 

,11 .05 .11 

.23 

.11 

.23 

.16 


END 


FIGURE 2. 


Would you select either of these project 
profiles as your own? Probably not exactly 
••you'll want to nake some adjustments, 
but you'll end up with between 6 and 10 
distinct phases of a system development 
cycle^^and the best part of it is that 
you are not being forced to accept 
anyone else's idea of what phases make 
up a total project plan^^this is your 
plan for your project in your company. 


Assign Percentages to Each of the 
Phases of Your System Life Cycl e 


This is a bit harder to do. It all 
depends on how accurately you have kept 
records on previous projects. Also, 
unless you have a very specialized group, 
you are likely to have more than one 
type of system life cycle, e.g. small 
batch systems, intermediate batch systems, 
large batch systems, small on-line sys- 
ems, intermediate on-line systems, large 
on-line systems, etc. 


START 


What do you do if you haven't ac- 
cumulated enough historical data to assign 
percentages to each phase? You start 
right now and collect as much data as you 
can for future estimates. In the mean- 
time, you have to work with what you have. 
This may well be only rough "guesstimates" 
--maybe not the most accurate information, 
but if you apply these to a profile in 
which you have confidence, you're already 
far ahead of the old way of pulling 
numbers out of the air: 


Remember, once the model is built, it's 
easy enough to change and refine the 
percentages as you learn more about your 
project life cycle. 


At this point, your life cycle profile 
might look something like Figure 2 for a 
small batch system or Figure 3 for a large 
on-line system. 


Typical Small Batch System 
Life Cycle 


FUN CON DBS SPC COD UNI SYS 

.18 .09 .18 .10 .06 .09 .30 


END 


FIGURE 3. 


Typical Large On-Line System 
Life Cycle 
where FUN ■ Funciional Requirements 
Definiti on 

Conceptual System Design 
System Design 
Program Specifications 
Coding 
Unit Test 
System Test 


CON 

DES 

SPC 

COD 

UNI 

SYS 


Select Productivity Factors 


How many instructions per day can you 
expect your programmers to produce? You 
will probably have more than one number 
here--the programming language used will 
be a factor. The key point here is: Only 

you know your environment. Since you have 
probably implemented projects before, all 
that needs to be done is to add the lines 
of code (source or delivered instructions- 
-it doesn't matter which you use--as long 
as you are consistent) and divide by the 
number of man-days reported on the project. 


The strongest objections are likely to 
be raised here in the form of: 


"But what if I don't have data from 
previous projects?" 


The only answer I can give is: You 

should have kept detailed records, but if 
you haven't there is no better time than 
now to begin. 


"Why instructions per day? How can I 
expect my programmers to turn out a 
fixed number of lines of code every 
day? How can they sustain such a 
daily rate of production?" 


This is not an easy question to answer. 
Until recently, no better unit of measure- 
ment has been found. 
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Lttely, there h»s been Increasing dis- 
cussion of an alternate measure, person- 
months (or days) per unit (e.g. 1000 lines) 
of code. This measure seems to have great 
merit, especially when applied to large 
systems, particularly where there is a 
high degree of scaffolding and much non- 
coding activity must be factored into 
overall costs. The typical computer user, 
however, tends to feel more comfortable 
with the traditional lines per day and 
this is still a very useful measure at 
the low and intermediate part of the 
scale . 

For these applications, where the 
great majority of project personnel are 
analysts and programmers, it is still the 
easiest to relate to. 

After all, when a system is delivered, 
the source code is there for all to see 
and it is preserved as part of the 
documentation. The only other data that 
has to be kept is an accurate report of 
hours or days spent in programming develop- 
ment. This data is vital if you ever want 
to control your projects rather than have 
your projects control you. 

Establish Estimating Basis 


Again, let me emphasize that you can 
estimate either way, as long as you apply 
the factors consistently. 

Estimate the Total Number of 

Instructions in the Finished System 

This is not as difficult as it may 
seem. Of course, if you don't have the 
slightest idea of where to begin, you 
shouldn't bo estimating yet. A good deal 
of design work needs to be do'ne. The 
earliest point at which an estimated 
instruction count can be made is at the 
completion of a conceptual design. A 
re-estimate should be made at the end of 
detailed program design and after program 
specifications and/or flowcharts are done. 
You will then be able to refine the ac- 
curacy of your earlier project estimates. 

Any experienced programmer should be 
able to guess the approximate number of 
lines of code from a combination of his 
previous experience, knowledge of other 
programs of various sizes, and a look at 
the specifications or flowchart or 
narrative of a proposed new program. It 
may not be a guarantee of actual final 
program size, but it's the best, most 
consistently accurate, self-correcting 
measurement criteria available. 


Let's say you have concluded that rea- 
sonable productivity factors for your 
installation are 18 lines of code per day 
for COBOL (which mny generate from 40 to 
60 actual deliverable instructions) and 
25 lines per day for Assembler. These 
numbers are meaningless without one more 
piece of information--over what part of 
your system life cycle do these factors 
apply? 

Take a 1000 line program as an example. 
If you mean 18 lines per day for the entire 
project from start to finish, the estimate 
is 1000/18 or 56 man-days. However, if you 
are measuring 18 lines per day from the 
start of the program specifications 
through the end of unit test, for the large 
on-line system profiled in Figure 3, the 
56 man-days accounts for only the middle 
portion, or 25\ of the system life cycle. 
The total technical man-days would be 
56/. 25 , or 224. 


Calculate Technical Man-Days 

Divide the total number of estimated 
Instructions by the productivity factor, 
e.g. 


A vvu 1 t rue t 

18 instr/day 


A WMi a 


^ w tM ms i( ' 


w X 


person-days, if you 
are so inclined 

If the 18 i ns t rue t i ons / day factor was 
developed to apply over your entire system 
life cycle, stop here. You have the total 
technical man-days. If the instructions 
P*^ day factor applies only to a percent- 
age of your total system life cycle, divide 
the man-day figure by the percentage. For 
example, if it applies over 50\ of the 
cycle, divide 56 by .50 to get 112 man- 
applies to 6i\ of the cycle, 
divide 56 by ,63 to get 89 man-days. 

This technique works well in a steady- 
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state environment, where the project being 
estimated represents no groat changes in 
approach or technology such as the first 
data base system or the first use of 
structured programming in the organization. 

Caution must be taken when the develop- 
ment environment is in a state of trans- 
ition. If, for example, we have found a 
way to double the productivity of coding 
and unit test without affecting the 
duration of the other project phases, we 
must reassess the life cycle profile. It 
must be modified to reflect a lower 
percentage for the phases in which pro- 
ductivity has increased and a higher 
percentage for the others. Otherwise, 
the casual application of ratios could 
inadvertently reduce the time allotted 
for all phases, not just those which 
benefited from a productivity increase. 

Translate into Time-Phased Project Plan 

Still with me? Good! We're almost 
finished. The last step is to go from a 
raw figure of technical man-days to a time 
-phased project plan. Users of this tech- 
nique have found that it works best for a 
"square- root” manpower vs. time distri- 
bution. For example, if your total 
technical man-days comes out to be 720, 
which divided by 20 days per month yields 
36 man-months, the project should take 6 
people 6 months to complete. If you try 
to complete the project in one month using 
36 people or in 36 months with one person, 
you're not likely to make it within the 
36 man-month estimate. 

The total effort expended will 
inevitably be somewhat greater, in the 
first case because of the increased 
interaction between 36 people and the 
sharing of other limited resources such as 
computer time. In the second case, three 
years is a long time and you can be sure 
that design changes and personnel changes 
will lengthen the project. 

After a while, you'll be able to adjust 
the basic technical man-days based on 
these types of time frame or manpower 
constraints without too much trouble. 

Other "extras" you may want to consider in 


arriving at a realistic total cost for the 
project are project management and doc- 
umentation, if these are not already part 
of your system profile. How many man-days 
you allocate for these functions is 
highly subjective and varies considerably 
from one installation to another. 

The Impact of Data Base/Data Commun l eat ions 
FVogram Products and Interactive Program 
Development 

The use of these system development 
tools can easily be taken into account 
with System Life Cycle Estimation. They 
are likely to impact project development 
in two ways: 

* Reducing the number of lines of code 
required to be written, because 

Data Base/Data Communications systems 
provide many of the data management 
functions which would otherwise have 
to be designed and programmed each 
time. 

* Increasing the number of lines of 
code per day which a programmer can 
be expected to produce because of 
the reduced testing and debugging 
turnaround time provided by inter- 
active development. 

With System Life Cycle Estimation, just 
know which of these tools you will bo using 
and take them into account in setting up 
your productivity factors and in estimating 
the total lines of code to be produced. 

Estimating in a Structured, Top-Down 
Environment 

If your project is being developed 
using one or more of the Improved Pro- 
gramming Technologies (Structured Pro- 
gramming, Top-Down Development, HIPO, Chief 
Programmer Team Operations, Development 
Support Libraries and Structured Walk- 
Throughs) System Life Cycle Estimation is 
just as valid as it is in the conventional 
environment. The top-down approach usually 
alters the shape and composition of a 
typical project profile. The major dif- 
ferences are; 
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* Detailed design, coding, unit test, 
integration teat and documentation 
tend to overlap and should be con* 
sidered as a single phase in system 
development. Therefore, these types 
of projects will have fewer develop- 
ment phases, e.g. 

1. Feasibility Study 

2. System Design 

3. Top-Down Development 

4. System Test 

* The percentage of total effort 
devoted to system test will be re- 
duced, because the top-down approach 
brings a more fully checked-out 
system into the system test phase. 

* The productivity factors (instruc- 
tions per day) are likely to be 
substantially higher. 

* The System Design phase is typically 
longer in this environment. 

CONCLUSION 

Now you're an expert in System Life 
Cycle Estimation. It's easy to use, and 
it works. You can do the calculations 
manually, or if you're skilled in pro- 
gramming in any interactive language (e.g. 
APL or BASIC), you can write a simple 
program to accept input values for project 
profile, language type, number of instruc- 
tions and productivity factors, and print 
out the estimates automatically. 

The only condition of use which I ask 
you to accept is: If you are not satis- 

fied with SLICE'S predictive accuracy the 
first time you use it, don't reject the 
technique yet--try it a second time. 

After you have properly applied the 
technique at least twice, I estimate that 
it will become a permanent part of your 
own life cycle. 
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